Amazon ECSの新たなデプロイツールとなるAWS CopilotがGAに！ECS環境の構築が便利になるぞ！！

コンサル部のtobachi（@toda_kk）です。

2020年11月23日に、Amazon ECS CLIの後継となるデプロイツールとして、AWS CopilotがGAになりました！

以前からベータ版として提供されていましたが、GAとなったことで、Amazon ECS環境のデプロイツールの1つとしてProduction利用においても検討可能になったのではないかと思います。

AWS Copilotの基本的な機能や使い方については、ベータ版発表の頃にすでに本ブログでも紹介されています。

本記事では、改めてAWS Copilotの機能や使い方を確認するとともに、ベータ版からGAの間にどんな機能が追加されたのか、そしてAWS Copilotにはどのような使いどころがあるのかを考えてみたいと思います。

改めて、AWS Copilotを動かしてみた

新たに用意された公式ドキュメントを参考にしながら、実際にECSクラスターの環境を構築してみます。

クラスターの構築およびサービスやタスクの起動は、copilot initコマンドを実行しいくつかの項目を対話的に入力するだけでできてしまいます。簡単ですね〜。

$ copilot init
Welcome to the Copilot CLI! We're going to walk you through some questions
to help you get set up with an application on ECS. An application is a collection of
containerized services that operate together.

Application name: example-app
Workload type: Load Balanced Web Service
Service name: front-end
Dockerfile: ./Dockerfile
Ok great, we'll set up a Load Balanced Web Service named front-end in application example-app listening on port 80.

上記コマンドを実行すると "copilot" ディレクトリが作成されます。

.
├── copilot
    └── front-end
        └── manifest.yml

ディレクトリの構造は上記のように、"copilot" 配下にService名のディレクトリが作成され "manifest.yml" というマニフェストファイルが作成されます。このマニフェストファイルを元に、実際にECSクラスター上で稼働するサービスやタスクが作成されるわけです。

また、initコマンドを実行することで、AWSリソースの実態としてはCloudFormationスタックが作成されます。特に、ECSのサービスを作成するスタックについてはcopilot svc packageというコマンドで実際の内容を確認できます。--output-dirオプションを付与すると、テンプレートとなるYAML形式のファイルと、パラメーターとなるJSON形式のファイルが指定したディレクトリに出力されます。

$ copilot svc package -n front-end -e test --output-dir ./infrastructure

GAまでに追加された機能

公式GitHubリポジトリにてリリースノートが公開されているので、これを参考にしながら現時点でAWS Copilotに何ができるのかを確認してみます。

まず、ベータ版でも実装されていた機能を確認します。AWS Copilotにおける重要な概念として下記がありました。詳細は上にも記載した本ブログの過去の記事を参考にしていただければと思いますが、ざっと説明するとこういったものです。

• Application: 開発・運用するアプリケーションの単位
• Environment: アプリケーションを稼働させる環境の単位
• Service: dockerイメージを起動する単位（ECSにおける「サービス」）
  • Load Balanced Web Service / Backend Service に分かれる

これに加えて、下記2つの概念が機能として追加・拡張されました。

• Job
• Pipeline

Job

AWS CopilotにおいてはServiceと対になるような概念です。具体的には、指定したタイミングに応じて実行されるタスクを設定できます。内容としては、イベントに応じて実行されるジョブです。（ただし、現時点では事前にスケジュールしたジョブしか設定できないようです。）

Serviceと同じように、YAML形式で書かれたマニフェストファイルを元にデプロイします。

$ copilot job deploy -n scheduled-job -e test

同様に、CloudFormationのテンプレートとパラメーターを下記のコマンドで確認できます。

$ copilot job package -n scheduled-job-e test --output-dir ./infrastructure

Pipeline

Pipelineはベータ版の頃から用意されていましたが、GAまでの過程でかなり機能が拡張されています。

Pipelineとは、ServiceやJobのデプロイパイプラインを扱う概念です。具体的には、CodePipelineを構築してくれます。

デプロイ自体はcopilot deployコマンドでもできますが、Pipelineを設定することで、自動ビルド・デプロイの仕組みを構築しCI/CDの環境を整えてくれます。

ECSクラスターといっしょにCodePipelineも作成できてしまうのは、かなり楽なのではないでしょうか。ただし、現時点ではソースコード管理のリポジトリとしてGitHubしか指定できないようです。今後はCodeCommitやGitLabなど他のリポジトリも指定できるようになることを期待します。

現時点でAWS Copilotにできないこと

GAになったとはいえ、Amazon ECSを扱う上でデプロイツールとしてのAWS Copilotにはまだまだ足りていない部分もあるかと思います。

少なくとも現時点では、基本的にService/Jobのマニフェストファイルでパラメーターとして指定できない要素については、AWS Copilotだけでは設定できないでしょう。思いつく限りではありますが、具体的に下記のような設定は実現できていないと思われます。

• 既存のECSクラスターにService/Jobをデプロイできない。
• ECSクラスターをEC2インスタンスで構築できない。
• Load Balanced Web Serviceで利用するApplication Load Balancerに独自ドメインやACMを自動で付与できない。
• 既存のApplication Load Balancerを使えない。
• AWS App Meshと連携できないためサービスメッシュを構築できない。
• （バグなのかもですが、同じVPC上に異なるEnviromentを作成できないっぽい。）

とはいえ、一般的な運用方針としては、AWS Copilotに限らず1つのツールで全てをカバーしようとするより、いくつかのツールを使い分けながら構築・運用していくべきでしょう。また、ケースバイケースではありますが、一部の機能についてはAWS CLIやマネジメントコンソールから手動で設定変更するという運用が適切な場合もあるでしょう。

AWS Copilotの使いどころ

これまで見てきたように、AWS Copilotで規定されている概念はAmazon ECSの概念をさらに抽象化させたようなものになっています。

ここからは完全に私見となりますが、他のデプロイツールと比較したAWS Copilotの特徴と使いどころについて考えてみたいと思います。

AWS Copilotでは、開発・運用するアプリケーションを大きな1つの単位（Application）として扱い、イテレーションのフェーズごとに複数の環境にデプロイすることを考えています。

その際、Production/Staging/Development といった各環境におけるVPC/SubnetやECSクラスターといったAWSリソースについては、Environmentという形で抽象化されています。少なくともアプリケーションレイヤーにおける開発者の立場からすると、各環境がどのようなAWSリソース上に配置されているのか、あまり意識しなくて良いようになっていると思います。

また、インフラレイヤーとしてAWSリソースを構築・管理する立場においても、ECSクラスターをどのようなネットワーク環境（VPC/Subnet）の上で構築するのかといったことを管理しなくて済みます。

Environmentという概念によって、アプリケーションの起動に必要なAWSリソース（VPC/Subnetといったネットワーク環境だったり、dockerイメージだったり、CI/CDの仕組みだったり、ECSの設定だったり……）をまるっとまとめて記述することができるため、アプリケーションが稼働するためのレイヤーとそれ以外のレイヤーを分離して考えることができます。

言ってしまえば、アプリケーションレイヤーを下方向に拡張し、アプリケーションが起動するためのリソースの管理をまるまるアプリケーション開発者に渡してしまうことも可能です。例えば、アプリケーションで新規開発している機能について検証したい場合、既存の環境とは分離された一時的な検証用の環境を、アプリケーション開発者自身がAWS Copilotを用いて作成する、といったような運用も考えられるのではないでしょうか（もちろん、権限管理をどうするかなど別の課題は発生しますが。）

これから新たにAmazon ECSを導入する際に、環境を構築するためのツールとしてAWS Copilotは強力な選択肢となりうるでしょう。それだけでなく、すでにECSの構築・運用に慣れ親しんでいる場合でも、AWS Copilotが提供してくれる概念に乗っかることでアプリケーション開発の速度向上やインフラ運用の簡易化が望めるのではないでしょうか。

今後の機能改善によって、そんな未来がくることを期待しています。

今後の展開と期待

改めて、ECSクラスターを管理する上で大変便利なツールであるということが確認できました。

その上で、既存のクラスターのデプロイ手段をAWS Copilotで置き換えられるか、というところが気になります。長く稼働しているクラスターに対しては、どうしてもAWS CLIなどスクリプトを作り込んでしまっており保守性に欠けてしまうというケースもあるのではないでしょうか。

この辺りはどこまでやるかという話ではありますが、いわゆる「秘伝のたれ」を継ぎ足し続けずに済む手段となりうるのであれば、AWS Copilotの使いどころも広がるのではないかと思います。

また、Amazon ECSのデプロイツールは他にもいくつかあり、これらとの使い分けをどのように考えるか気になるところではあります。

特に、つい先日にはDocker ComposeのAmazon ECSへの対応がGAとなったこともあり、上手い使い分けや組み合わせを見つけたいところです。

こういった点は、これからも調査と検証を続けていきたいと思います。

今後の展開としては、公式のGitHubリポジトリにてロードマップという形で対応予定の機能が挙げられています。既存のタスク定義の上書き、DNS管理機能の拡充、Network LoadBalancerへの対応など、ますます便利になるような変更がありそうです。

いずれにせよ、Amazon ECSがさらに便利で使いやすくなるのではないでしょうか。周辺ツールだけでなく、ECS自体の今後のアップデートにも期待が高まります。

以上、コンサル部のtobachi（@toda_kk）でした。